Naming Service Overview

The Java IDL Name Server

The CORBA COS (Common Object Services) naming service provides for objects something like what file system directories (folders) provide for files: Object references can be stored in and looked up by name in directory-like objects called contexts. The Java IDL product includes a simple implementation of the COS naming service specification, called the Java IDL name server. For an applet or application to use COS naming, its ORB must know the name and port of a host running a naming service. The naming service can either be the Java IDL name server or another COS-compliant name service. Java IDL name-object bindings are not persistent; when the server is terminated, the bindings disappear.

You must start the Java IDL name server before an application or applet that uses its naming service. Installation of the Java IDL product creates a script (Solaris: nameserv) or batch file (Windows NT: nameserv.bat) that starts the Java IDL name server. The script or batch file is located in the same directory (folder) as the idltojava compiler. Start the name server so it runs in the background.

If you do not specify otherwise, the Java IDL name server listens on port 900. Specify a different port, for example, 1028, as follows:

   nameserv -ORBInitialPort 1028

To stop the Java IDL name server, use the relevant operating system command, such as kill. Note that names registered with the Java IDL name service disappear when the server is terminated.

Your applet or application can bind objects by names into the root context including new contexts; the example server performs a simple binding. Any changes you make, however, are erased when the name server is next started.

The COS Naming Service

Note: The contents of this section are excerpted from the Object Management Group's Common Object Services Specification Volume 1 (see Naming Service in the OMG's Adopted Specifications).

A name-to-object association is called a name binding. A name binding is always defined relative to a naming context. A naming context is an object that contains a set of name bindings in which each name is unique. Different names can be bound to an object in the same or different contexts at the same time. There is no requirement, however, that all objects must be named.

To resolve a name is to determine the object associated with the name in a given context. To bind a name is to create a name binding in a given context. A name is always resolved relative to a context -- there are no absolute names.

Because a context is like any other object, it can also be bound to a name in a naming context. Binding contexts in other contexts creates a naming graph (as in a file system, inserting directories in directories creates a naming graph). A naming graph allows more complex names to reference an object. Given a context in a naming graph, a sequence of names can reference an object. This sequence of names (called a compound name) defines a path in the naming graph to navigate the resolution process.

Names

Many of the operations defined on a naming context take names as parameters. Names have structure. A name is an ordered sequence of components.

A name with a single component is called a simple name; a name with multiple components is called a compound name. Each component except the last is used to name a context; the last component denotes the bound object. The notation:

	< component1 ; component2 ; component3 >

indicates the sequences of components.

Note - The semicolon (;) characters are simply the notation used in this document and are not intended to imply that names are sequences of characters separated by semicolon.

A name component consists of two attributes: the identifier attribute and the kind attribute. Both the identifier attribute and the kind attribute are represented as IDL strings.

Note - Both the identifier and kind are interpreted by the Java IDL name server.

The kind attribute adds descriptive power to names in a syntax-independent way. Examples of the value of the kind attribute include c_source, object_code, executable, postscript, or " ". The naming system does not interpret, assign, or manage these values in any way. Higher levels of software may make policies about the use and management of these values. This feature addresses the needs of applications that use syntactic naming conventions to distinguish related objects. For example Unix uses suffixes such as .c and .o. Applications (such as the C compiler) depend on these syntactic convention to make name transformations (for example, to transform foo.c to foo.o).

The lack of name syntax is especially important when considering internationalization issues. Software that does not depend on the syntactic conventions for names does not have to be changed when it is localized for a natural language that has different syntactic conventions -- unlike software that does depend on the syntactic conventions (which must be changed to adopt to new conventions).

To avoid issues of differing name syntax, the Naming Service always deals with names in their structural form (that is, there are no canonical syntaxes or distinguished meta characters). It is assumed that various programs and system services will map names from the representation into the structural form in a manner that is convenient to them.

Example Scenarios

This section provides two short scenarios that illustrate how the naming service specification can be used by two fairly different kinds of systems -- systems that differ in the kind of implementations used to build the Naming Service and that differ in models of how clients might use the Naming Service with other object services to locate objects.

In one system, the Naming Service is implemented using an underlying enterprise-wide naming server such as DCE CDS. The Naming Service is used to construct large, enterprise-wide naming graphs where NamingContexts model "directories" or "folders" and other names identify "document" or "file" kinds of objects. In other words, the naming service is used as the backbone of an enterprise-wide filing system. In such a system, non-object-based access to the naming service may well be as commonplace as object-based access to the naming service. For example, the name of an object might be presented to the DCE directory service as a null-terminated ASCII string such as "/.../DME/nls/moa-1/ID-1".

The Naming Service provides the principal mechanism through which most clients of an ORB-based system locate objects that they intend to use (make requests of). Given an initial naming context, clients navigate naming contexts retrieving lists of the names bound to that context. In conjunction with properties and security services, clients look for objects with certain "externally visible" characteristics, for example, for objects with recognized names or objects with a certain time-last-modified (all subject to security considerations). All objects used in such a scheme register their externally visible characteristics with other services (a name service, a properties service, and so on).

Conventions are employed in such a scheme that meaningfully partition the name space. For example, individuals are assigned naming contexts for personal use, groups of individuals may be assigned shared naming contexts while other contexts are organized in a public section of the naming graph. Similarly, conventions are used to identify contexts that list the names of services that are available in the system (e.g., that locate a translation or printing service).

In an alternative system, the Naming Service can be used in a more limited role and can have a less sophisticated implementation. In this model, naming contexts represent the types and locations of services that are available in the system and a much shallower naming graph is employed. For example, the Naming Service is used to register the object references of a mail service, an information service, a filing service.

Given a handful of references to "root objects" obtained from the Naming Service, a client uses the Relationship and Query Services to locate objects contained in or managed by the services registered with the Naming Service. In such a system, the Naming Service is used sparingly and instead clients rely on other services such as query services to navigate through large collections of objects. Also, objects in this scheme rarely register "external characteristics" with another service - instead they support the interfaces of Query or Relationship Services.

Of course, nothing precludes the Naming Service presented here from being used to provide both models of use at the same time. These two scenarios demonstrate how this specification is suitable for use in two fairly different kinds of systems with potentially quite different kinds of implementations. The service provides a basic building block on which higher-level services impose the conventions and semantics which determine how frameworks of application and facilities objects locate other objects.

Design Principles

Several principles have driven the design of the Naming Service:

1. The design imparts no semantics or interpretation of the names themselves; this is up to higher-level software. The naming service provides only a structural convention for names, e.g. compound names.

2. The design supports distributed, heterogeneous implementation and administration of names and name contexts.

3. Names are structures, not just character strings. A struct is necessary to avoid encoding information syntactically in the name string (e.g., separating the human-meaningful name and its type with a ".", and the type and version with a "!"), which is a bad idea with respect to the generality, extensibility, and internationalization of the name service. The structure define includes a human-chosen string plus a kind field.

4. Naming service clients need not be aware of the physical site of name servers in a distributed environment, or which server interprets what portion of a compound name, or of the way that servers are implemented.

5. The Naming Service is a fundamental object service, with no dependencies on other interfaces.

6. Name contexts of arbitrary and unknown implementation may be utilized together as nested graphs of nodes that cooperate in resolving names for a client. No "universal" root is needed for a name hierarchy.

7. Existing name and directory services employed in different network computing environments can be transparently encapsulated using name contexts. All of the above features contribute to making this possible.

8. The design does not address namespace administration. It is the responsibility of higher-level software to administer the namespace.

The CosNaming Module

The CosNaming Module is a collection of interfaces that together define the naming service. This module contains two interfaces:

The NamingContext interface
The BindingIterator interface

The CosNaming Module is shown below. Note that Istring is a placeholder for a future IDL internationalized string data type.

module CosNaming
{
	struct NameComponent {
		Istring id;
		Istring kind;
	};
 
	typedef sequence <NameComponent> Name;
 
	enum BindingType {nobject, ncontext};
 
	struct Binding {
		Name         binding_name;
		BindingType  binding_type; 					
	};
 
	typedef sequence <Binding> BindingList;
 
	interface BindingIterator;
 
	interface NamingContext {
 
 
		enum NotFoundReason { missing_node, not_context, not_object};
 
		exception NotFound { 
				NotFoundReason why;
				Name rest_of_name;
		};
		exception CannotProceed {
				NamingContext cxt;
				Name rest_of_name;
		};	
		exception InvalidName{};
		exception AlreadyBound {};
		exception NotEmpty{};
		
		void bind(in Name n, in Object obj)		
 
			 raises(NotFound, CannotProceed, InvalidName, AlreadyBound);
		void rebind(in Name n, in Object obj)
 
			 raises(NotFound, CannotProceed, InvalidName);
			 void bind_context(in Name n, in NamingContext nc)
			 raises(NotFound, CannotProceed, InvalidName, AlreadyBound);
 
		void rebind_context(in Name n, in NamingContext nc)
			 raises(NotFound, CannotProceed, InvalidName);
 
		Object resolve (in Name n)
			 raises(NotFound, CannotProceed, InvalidName);
 
		void unbind(in Name n)
			 raises(NotFound, CannotProceed, InvalidName);
 
 
		NamingContext new_context()
 
		NamingContext bind_new_context(in Name n)
		 	 raises(NotFound, AlreadyBound, CannotProceed, InvalidName);
 
		void destroy( )
		 	 raises(NotEmpty);
 
		void list (in unsigned long how_many, 
					out BindingList bl, out BindingIterator bi)
	};
 
	
	interface BindingIterator {
 
		boolean next_one(out Binding b);
 
		boolean next_n(in unsigned long how_many, 
					out BindingList bl);
 
		void destroy();
	};
};

Binding Objects

The binding operations name an object in a naming context. Once an object is bound, it can be found with the resolve operation. The Naming Service supports four operations to create bindings: bind, rebind, bind_context and rebind_context.

bind: Creates a binding of a name and an object in the naming context. Naming contexts that are bound using bind do not participate in name resolution when compound names are passed to be resolved.
rebind: Creates a binding of a name and an object in the naming context even if the name is already bound in the context. Naming contexts that are bound using rebind do not participate in name resolution when compound names are passed to be resolved.
bind_context: Names an object that is a naming context. Naming contexts that are bound using bind_context() participate in name resolution when compound names are passed to be resolved.
rebind_context: Creates a binding of a name and a naming context in the naming context even if the name is already bound in the context. Naming contexts that are bound using rebind_context() participate in name resolution when compound names are passed to be resolved.

Resolving Names

The resolve operation is the process of retrieving an object bound to a name in a given context. The given name must exactly match the bound name. The naming service does not return the type of the object. Clients are responsible for "narrowing" the object to the appropriate type. That is, clients typically cast the returned object from Object to a more specialized interface.

Names can have multiple components; therefore, name resolution can traverse multiple contexts.

Note - Both the identifier and kind are matched when the IDL Java name server resolves a name.

Unbinding Names

The unbind operation removes a name binding from a context.

Creating Naming Contexts

The Naming Service supports two operations to create new contexts: new_context and bind_new_context.

new_context: This operation returns a naming context implemented by the same naming server as the context on which the operation was invoked. The new context is not bound to any name.
bind_new_context: This operation creates a new context and binds it to the name supplied as an argument. The newly-created context is implemented by the same naming server as the context in which it was bound (that is, the naming server that implements the context denoted by the name argument excluding the last component).

Deleting Contexts

The destroy operation deletes a naming context:.

Listing a Naming Context

The list operation allows a client to iterate through a set of bindings in a naming context.

The list operation returns at most the requested number of bindings in BindingList bl.

If the naming context contains additional bindings, the list operation returns a BindingIterator with the additional bindings.
If the naming context does not contain additional bindings, the binding iterator is a nil object reference.

The BindingIterator Interface

The BindingIterator interface allows a client to iterate through the bindings using the next_one or next_n operations:

next_one: This operation returns the next binding. If there are no more bindings, false is returned.
next_n: This operation returns at most the requested number of bindings.
destroy: This operation destroys the iterator.